Project Failure: A Review of the Literature

Steve Pan

 

Introduction:

Why do IT projects fail? A 2012 Gallup Business Review article revealed that IT project failures account for a dollar loss of 50 to 150 billion dollars in the US and up to 142 billion Euros a year in Europe. This paper will examine the reasons why IT projects fail as well as strategies to mitigate or prevent IT projects from failing.

 

Section 1: The cost of failed IT projects.

 

            IT projects are major undertakings in virtually every type of organization. Consider for example the IRS and its multi-decade, multibillion dollar a year efforts to modernize its IT systems. Consider the agency’s Customer Account Data Engine (CADE) effort. An early project designed to replace the cumbersome, sequential file system that contained the entire sum of data the IRS had on over 200 million taxpayers, CADE ran over budget by 37 million dollars and nearly 30 months behind schedule. Started in 1998, it was cancelled in 2004 and replaced by the CADE2 project.  A GAO report later found that the reasons for failure were myriad- among them common woes such as poor project management, inadequate requirements definitions, scope creep, and lax oversight of cost and schedule projections.[1]

           

That is not to say that the private sector is immune to these issues. Consider the notorious FoxMeyer ERP debacle. Once one of America’s largest pharmaceutical distribution companies, FoxMeyer purchased a SAP ERP in 1993 with the stated goals of streamlining their business and leveraging technology to boost productivity and reduce operating costs. Instead, by 1996 the company had gone bankrupt and its bankruptcy trustee filed suit against SAP for 500 million dollars in an attempt to recoup some of the costs of the botched ERP implementation.[2]

 

Globally, one estimate of failed IT projects claims that six trillion dollars are wasted every year on IT projects that no nowhere. It is clear that in this era of information and technological dominance that IT project failures deserve more research, analysis, and recommendations on how to avoid these costly project failures.

 

Section 2: Methods

            This paper utilizes a literature review approach to the issue. 10 articles were selected from Google Scholar based on ­citation count with preference given to papers that were more frequently cited in academic literature. Each article deals with the issue of project failure using its own methodological approach and all ten articles were chosen with an eye towards comparing and contrasting approaches to dealing with the issue.

 

Section 3: Summaries

 

The most cited article is “The Causes of Project Failure” by Jeffrey Pinto and Samuel Mantel Jr in the November 1990 issue of IEEE Transactions on Engineering Management. Pinto and Mantel start by discussing the difficulty in operationalizing project failure since definitions can vary greatly as to what a failed project actually entails. For example, if a project comes in 20 years late and a billion dollars over budget does that constitute a failure? Technically it was finished and not cancelled but at an enormous cost to the organization sponsoring the project. As such, the authors stated that the primary purpose of the paper was to see if “there exist[s] patterns of causes of project failure depending on three contingency variables, 1) the way in which failure is defined, 2) the type of project being studied; and 3) the stage of the project’s life cycle at the time it is assessed.”[3]

Pinto and Mantel accomplish this task by issuing a survey to 130 project managers who were members of the Project Management Institute (PMI). The survey data was then used to either accept or reject the three hypotheses that the authors posited at the beginning of the article regarding project failure. Hypothesis 1 is: “The perceived causes of project failure will vary, seems reasonable, therefore, to expect that the causes of depending on which outcome measure is used to assess performance.”[4] Hypothesis 2 is: “The perceived causes of project failure will vary, depending on whether the project is in the strategic or tactical stage of its life cycle.”[5] It should be noted that the authors operationalize lifecycle with a fairly simple rubric: strategic stage refers to the project’s conception and initial planning and development while tactical stage involves the actual work of getting the project done. Lastly, the third hypothesis is The perceived causes of project failure will vary depending upon the type of project assessed: construction or R&D.”[6]

Not surprisingly, the author’s survey data confirms their hypotheses. H1 is confirmed when the diverse group of project management professionals responded to their survey with a myriad of explanations for why projects fail, from such overarching issues as client acceptance and lack of clear mission to more operational difficulties like inadequate tech support or personnel.[7] The authors also found evidence in the survey that support H2 and H3, showing projects not only fail from a multitude of reasons, but also that failures in inadequate mission planning and client acceptance tend to happen earlier in the project, while failures attributed to operational tasks occurred later during the implementation of the projects.I

While the study shows a lot of scientific rigor in its quantitative analysis of survey data, it has to be taken with a grain of salt in that the hypotheses used were so vague and broad that hardly anyone would disagree with the notion that projects fail for a lot of reasons. Ultimately, the lasting contribution of Pinto and Mantel Jr. to the problem of project failure is showing that chronologically projects fail for different reasons at different parts of the project life cycle.

Kurt Linberg of Walden University operationalizes project failure in a far more granular method in his article “Software developer perceptions about software project failure: a case study.” Drawing upon previous work by a consulting firm Linberg considers a project a success if it “meets its budget, delivery, and business objectives.”[8] His methodology here is not a latitudinal study involving large reams of quantitative survey data, but a more longitudinal approach where he follows a team of experienced software developers at a large corporation over the years. By drawing upon ethnographic-style research and interviews, he debriefs them on what they considered their most and least successful projects are. Key takeaways from the software developers on what a project a success include “a) the project was a technical challenge, b) the project worked the way it was intended to work, and c) the team was small and high performing.”[9] The developers interviewed emphasized that it was important for management to contain scope creep, remain calm and collected during setbacks and crises, and that the schedule for deliverables was set in a sane manner that allowed developers enough time to finish work.

On the other hand, the developers had much more to say about projects they worked on that were failures. Of note was the common theme that resonates with Pinto and Mintel Jr.’s work: “poor management and market research.”[10] By poor management, the team opined on how their worst projects had leadership that was excessively pushy about deadlines or overpromised on what their team could accomplish within a limited timeframe. Interestingly, these two behaviors of poor project managers are the root cause of many of the “tactical” failures discussed by Pinto and Mantel Jr., such as inadequacy in staffing and uncontrolled scope creep. Ironically, by overpromising the client on what they can accomplish in order to stay in the client’s good graces, they eventually create an untenable situation of failure that arguably puts them in a worse off position than if they had kept the project goals and objectives reasonable and measured.

Also of note is how nuanced Linberg operationalizes project failure. He created a continuum of success and failure based on two outcomes: project is completed or project is cancelled. In his view, a project can be completed but be a failure (by “developing a product that causes customer discontent (not meeting quality expectations”), or can be cancelled formally but also highly successful (where “substantial learning [from the project] can be applied to future projects. Significant numbers of artifacts from the canceled project can be directly used on a future project.”)[11] Overall, I found Linberg to be more insightful and relevant based on the ethnographic approach he took compared to the sterile and objective survey method used by Pinto and Mantel Jr.

Kappelman, McKeeman, and Zhang take an approach geared towards preventative measures in their article, “Early Warning Signs of IT Project Failure: The Dominant Dozen.”[12] Their method was to scour literature to create a master list of Early Warning Signs (EWS). Armed with this list, they interviewed 138 IT project management professionals and invited them to rank the 53 items on their list using a 1-7 Likert scale, with 1 being least important EWS and 7 being the most important EWS. Results were compiled and ranked in order from most to least important based on survey data.

As discussed previously in both Linberg and Pinto’s work, leadership failure plays a prominent role in project failures. The top ranked EWS that Kappelman et. al’s work showed was “lack of top management support for project.” The other management related EWS include “project managers cannot effectively lead team or communicate with clients.” In terms of scope creep and systems analysis failures, the second highest ranked EWS was “functional, performance, and reliability requirements and scope are not documented,” showing the importance of information systems analysis and the proper scoping of projects.

Interestingly, the top ten EWS are an even mix of both leadership and procedural/documentation failures. Although the top cited EWS was a management failure, it appears that the project managers surveyed feel very strongly that a successful project depends not only on good leadership but also proper documentation and analysis.

Similarly, Cule and Schmidt et. al discuss ways to prevent project failure in “Strategies for Heading Off IS Project Failure.” They evaluate IT project risk through a prism of four different risk categories: client and environment (external risks) and self and task (internal risk).[13] Instead of attempting to mitigate every little risk factor that can result in a project failure, the authors’ philosophy is to group the myriad risks that a project  can face into the four categories mentioned above. The idea is that each group represents potential risks that have a common cause. For example, risk factors such as “lack of top management commitment to project” and “failure to identify all stakeholders” get lumped under the “client” risk category. The idea is that since all of them share similar root issues, an enterprising project manager will go and cultivate client relationships in such a way where those individual risk factors can be mitigated. One caveat the authors do mention for this approach is that the project management environment is highly dynamic, so that a universal guide to avoiding project failure cannot be realistically created for every scenario.

Al-Ahmad and Al-Fagih et. al also explore the idea of root causes of IT failure in “A Taxonomy of an IT Project Failure: Root Causes.” Their approach is similar to the one used by Cule and Schmidt et. al in that they attempt to drill the various blame factors attributed to project failure into a handful of root causes. Unlike the simplified four risk categories utilized in the Cule and Schmidt et. al study, Al-Ahmad et. al went with six root causes of IT failure: “project management, top management, technology, organizational, complexity, and size factors.” Despite being one of the most cited works in my Google scholar search, I found it to be extremely thin on content and their methodology borders on being a meta-analysis without the methodological rigor and analysis part of conducting a proper meta-analysis.[14]

Sometimes IT project failure can be the result of purchasing from or working with an outside vendor for a technology solution instead of inhouse development. Natovich categorizes three main risks that occurred during his case study of a project failure involving an outside vendor being brought in to be part of the solution: “Adversarial relationships and loss of trust between the vendor and the client; (b) Vendor management de-escalation of commitment; and (c) Difficulty in breaking the contractual engagement.”[15]

He draws these conclusions from the botched billing system overhaul that Israeli telecom giant Bezeq asked vendor AMS to design and develop. Like many large, multimillion dollar projects, AMS was not the only prime contractor selected. Bezeq had given authority to a smaller company to design some minor modules for the billing system as a settlement rather than fight the company in court over alleged improprieties during the vendor selection process. Natovich documents 6 key disagreements that are detailed in Figure 1 that started almost immediately after the parties signed their contract. Additionally, once AMS realized that the project was going to face heavy losses and a lack of cooperation with Bezeq, they began immediately de-escalating their commitment and involvement to the the contract while telling Bezeq executives the exact opposite. Natovich does not assign blame to just one party for this breakdown in cooperation- Bezeq had pushed AMS into a fixed cost contract and then almost immediately began scope creeping the requirements beyond what was agreed to. AMS underwent a top leadership change and decided later on that high risk telecom projects were not good uses of money and resources compared to more lucrative government and healthcare contracts. Overall, Natovich presents a compelling narrative of an outside vendor managed IT failure and lessons learned from the botched project, even if it is limited in scope to one company.

Equally important from learning about the causes of project failure is how to cope and move forward from it. Shepard et. Al use psychological theories of coping with loss and organizational theory to explore how organizations cope and deal with the fallout from a failed project. They discovered that people treated the loss and failure of a project they worked on the same way they would any personal failing- by applying a hedonic biased worldview- attributing success to their own intrinsic characteristics but blaming failures on environmental factors outside their own control.[16] Interestingly, they identified three psychological coping orientations to project failure- loss, restoration, and oscillation (where the subject experiencing loss bounces back and forth between grieving the loss and restoration of mental acuity towards current tasks). Overall, an interesting take on the psychological effects that project failure can have on employees.

Leadership also plays a role in project failures. An interdisciplinary group of professors in Australia conducted a meta-analysis of leadership attributes that play a role in successful and unsuccessful projects. In their search for leadership attributes that could be associated with project failure, they discovered that there were 5 commonalities to bad project leadership: no self awareness, no self regulation, no motivation, no empathy, and lastly no social skills.[17]

Verner et. al explore the idea of not only which factors are implicated in project failure, but which ones were most frequently implicated in a failed project. Their work reviewed 57 failed projects and looked for commonalities in each one and which ones occurred the most frequently. They found that most common factor was changing delivery dates (93% of projects) followed by underestimating project scope (81%), risks not assessed or managed (76%), staff not rewarded or recognized for working long hours (73%), delivery decision not made with adequate requirements information, and staff had unpleasant experience working on project (both also at 73%).[18] I found this one to be one of the more interesting articles dealing with project failure because it was the only one that looked at factors like employee morale and whether or not employees felt motivated or appreciated enough in their duties towards finishing the project.

Projects can also fail from poor budgetary controls. As Conboy demonstrates in “Project failure en masse: a study of loose budgetary control in ISD projects,” cost overruns can trigger a cascading panic in large organizations that cause the failures of other projects due to management attempting to control costs. His work shows that, even with tight line item budgetary controls (where each individual cost has to be approved by management), projects can often run catastrophically over budget.[19]

Lastly, politics is a part of any job. It shouldn’t be a surprise than that organizational politics can also cause a project to fail. Warne and Hart profile in a case study one project in the public sectors whose scope requirements and eventual size earned the enmity of multiple stakeholders because, although the project was necessary, it was how the project attempted to change the processes that made those government departments lobby against the completion of the project. In short, the stakeholders agreed that something needed to be done, as long as their own departments were spared from too much restructuring from the project.[20]

 

Section 4: Discussion and Conclusions

 

A 2012 study estimated that the worldwide cost of project failure was 3 trillion dollars.[21]This is a staggering sum of economic potential that has been wasted due to poor management, HR failures, scope creep, and other easily preventable nuisances. The ten articles reviewed showed that no failed project is alike— they all failed for different reasons. Indeed, outside of academia even business oriented sources geared towards CIOs list a litany of potential failure reasons.[22]

Project failures are not just consequence-free internal matters for an organization. When Cover Oregon, the Affordable Care Act-complaint state run exchange for Oregon failed, taxpayers lost out in millions as both prime contractor Oracle and client (Oregon) sued each other in an attempt to recoup costs legally.[23] Additionally, thousands of uninsured Oregonians had to endure delays in accessing coverage as the state shifted to the federal exchange website for its insurance market. Overall, the losses to taxpayers were at least 310 million dollars and projected to continue rising as the lawsuits start working their way through the courts.[24]

Cover Oregon’s factors in failure mirror those discussed in the literature review: unrealistic due dates, top management (in the form of the governor) seemingly uninterested in the success of the project, as well as feuding bureaucracies were just some of the dozens of reasons that a post-mortem report conducted on the failure revealed to the public.[25]

Not only does this issue plague public sector projects, but also private sector ones. Consider the London Stock Exchange’s (LSX) TAURUS upgrade, which would’ve moved the paper based processing of stock transactions to the digital realm. Massive scope creep and a last ditch effort to stitch together a “Frankenstein” software solution out of disparate parts failed epically and cost the LSX 75 million pounds. Other stakeholders collectively lost as much as 400 million pounds.[26] Cost overruns seem particularly acute in the ERP realm, where that particular failure factor seems endemic. For example, midsized food distribution company Whaley Foodservice sued ERP provider  Epicor over a botched ERP implementation that was expected to cost $190,000 but ended up totaling more than 1 million in charges.[27] This was not the only lawsuit that Epicor has been named in as a defendant over cost overruns and project failure- they have been taken to court by both a sheet metal company and a beverage distribution company over major cost overruns, scope creeping, and ultimately expensive failures in ERP implementation.[28] [29]

Ultimately, project failures will be an issue that plagues information system design and implementation for years to come as software and business requirements become more complex. However, through continued research into project failure causes and best practices to prevent or mitigate a costly failure these costs can be reduced and project risk ameliorated.